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As humans venture farther from earth for longer durations, it will become essentia! for 
those on the journey to have significant control over the scheduling of their own activities as 
well as the activities of their companion systems and robots. However, there are many 
reasons why the crew will not do all the scheduling; timelines will be the result of 
collaboration with ground personnel. Emerging technologies such as in-space message buses, 
delay-tolerant networks, and in-space internet will be the carriers on which the collaboration 
rides. Advances in scheduling technology, in the areas of task modeling, scheduling engines, 
and user interfaces will allow the crew to become virtual scheduling experts. New concepts of 
operations for producing the timeline will allow the crew and the ground support to 
collaborate while providing safeguards to ensure that the mission will be effectively 
accomplished without endangering the systems or personnel. 


I. Introduction 

F OR all past and current human space missions, the final scheduling of tasks to be done in space has been devoid 
of crew control, flexibility, and insight. Ground controllers, with minimal input from the crew, schedule the 
tasks and uplink the timeline to the crew or uplink the command sequences to the hardware. Prior to the 
International Space Station (ISS), the crew could make requests about tomorrow’s timeline, they could omit a task, 
or they could request that something in the timeline be delayed. This lack of control over one’s own schedule has 
had negative consequences (Ref. 1). There is anecdotal consensus among astronauts that control over their own 
schedules will mitigate the stresses of long-duration missions. On ISS, a modicum of crew control is provided by the 
“job jar.” Ground controllers prepare a task list (a.k.a. “job jar”) of non-conflicting tasks from which jobs can be 
chosen by the in-space crew. Because there is little free time and few interesting non-conflicting activities, the task- 
list approach provides ; little relief from the tedium of being micro-managed by the timeline. _ 

Scheduling for space' missions is a complex and laborious undertaking which, usually requires a large r^dre of 
trained specialists and suites of complex software tools. It is a giant leap from today’s ground-prepared timeline 
(with a job jar) to full crew control of their schedule. However, technological advances, currently in-work or 
proposed, make it reasonable to consider scheduling as a collaborative effort of the ground-based teams and the in- 
space crew. Collaboration would allow the crew to make minor adjustments, add tasks to suit their preferences, 
understand the reasons for the placement of tasks on the schedule, and provide them a sense of control over their 
own schedules. In foreseeable but extraordinary situations, such as quick response to anomalies and extended or 
unexpected loss of signal, the crew could have the autonomous ability to make appropriate modifications to the 
timeline, extend the timeline, or even start over with a new timeline. 

The Vision for Space Exploration (VSE), currently being pursued by the National Aeronautics and Space 
Administration (NASA), will send humans to Mars in a few decades. Stresses on the human mind will be 
exacerbated by the longer durations and greater distances, and it will be imperative to implement stress-reducing 
innovations such as giving the crew control of their daily activities. 

A. Major Consideration 

Implementation of crew collaboration will be driven by one major circumstance - the round-trip light-time delay 
between the Earth and Mars can be up to 44 minutes and will never be less than 6 minutes (Fig. I). Every 26 
months, Mars cycles between close approach and farthest retreat. Barring some breakthrough in propulsion 
technologies, a mission to Mars will take longer than two years during which the light-time delays will average over 
20 minutes. Normal voice conversations will be impossible. Instant transfer of information as provided by today’s 
earth-based internet will also be negated. The communication delays will change the way human missions are 
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to emergencies and mundane anomalies; they will attend 


operated. The crew will be the first responders 
autonomously to all alarms, switching the 
troublesome system to a safe mode and/or making 
quick repairs and reconfigurations. What we now 
think of as ground control teams will become 
ground support teams. 

The inability to have normal conversations 
with the ground, seeing the earth only as a point 
of light, having no immediate return to earth 
options, interacting only with their companions, 

having limited food choices, drinking recycled water, and doing the same maintenance tasks each day will make life 
stressful for the crew. Crew collaboration on the development of the daily schedule for themselves and for the 
systems they use and maintain will provide them necessary knowledge to execute the plan and necessary influence 
so that they will feel that they are in control of their own destiny. 



B. Collaboration 

Collaboration is working jointly to produce a product or to attain a goal. Usually collaborators share ideas, 
compromise on goals or methods, contribute where their expertise allows, and jointly arrive at an objective. There 
are two types of collaboration, interactive and passive. Interactive implies that the collaborators communicate during 
the collaboration process. Passive collaboration happens without direct communication. An instance of interactive is 
a group of authors who brainstorm the contents of a paper. An instance of passive collaboration is the progression of 
teachers who instruct children from early childhood into adults; another instance is the corps of guards who attend 
all the gates at an arena so that only ticket holders are allowed to enter. 

There are several methods which support interactive collaboration; often, these are used in combinations. The 
more common methods are listed below in approximate order of productivity. 

• Face-to-face - collaborators talk to one another across the table, use whiteboards, share notes, etc. 

• Teleconferencing and web conferencing — collaborators simulate being face-to-face using voice, 
possibly video, and sometimes an electronic white board or a shared computer “desktop.” 

• Custom software - an application designed to support collaboration on a specific task or product. 
Internet games are a common example of custom software. 

• Instant messaging and chat rooms - collaborators type messages which are displayed almost instantly 
for each collaborator. 

• File transfer - collaborators post and retrieye Hies using peer-to-peer transfer or a common drop box. 
Commercial products are available to automate this method. 

• Electronic forums - collaborators post messages on a message board. 

• Electronic mail - collaborators correspond by sending messages over the internet. 

• Postal mail - collaborators correspond by written mail. 

Passive collaboration is based on a concept of operations rather than communication. 

For earth-based support teams and humans on a mission to Mars, several of these collaboration methods will not 
be available and others (file transfer, electronic forums, and electronic mail) will be degraded. Custom software and 
the concept of operations can be tailored to deal with the time delays. Collaboration between the in-space crew and 
the ground support will, no doubt, use all the tools available including a delay-tolerant communication 
infrastructure, delay-tolerant scheduling software, and a specially tailored concept of operations. 


II. Concept of Operations 

Human missions to the moon and Mars will use extraordinarily complex hardware and software systems and will 
include significant technological and scientific investigations. The missions will extend for years, and ground 
support will require collaboration from many widely dispersed contributors. The cost to collect the ground-based 
planning and scheduling collaborators in a central location will be prohibitive. The only affordable solution will be 
to distribute the planning and scheduling efforts. It logically follows that if the planning and scheduling effort is to 
be distributed, it can be distributed to the crew on the moon, in transit to Mars and at Mars. Distributed planning and 
scheduling has been used to a small extent for ISS. Research into concepts of operations (Ref. 2) which maximize 
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the distribution and the cost savings has yielded viable results. f To be successfully accepted and implemented, a 
distributed concept of operations must be considered and developed beginning as early as possible. The concept 
proposed here is intended to be a starting point for the concept which will eventually be used to allow full 
distribution of the planning and scheduling function to all collaborators including the in-space crew. The concept has 
the additional advantage of giving the crew full autonomy if they should need it. Figure d shows the contributions to 
the planning and scheduling effort by different collaborators during the preparation of the preliminary plan on earth 
and after the plan is uplinked to the crew. Text messages, notes, email, and voice memos are not shown on the chart. 
The development of the schedule is divided into two phases, preliminary and final. Preliminary schedules are 
developed on the ground using a ground-based instance of the scheduling system. Before the beginning of each 
work day, the schedule is transferred to an in-space instance of the scheduling system. In-space crew has time- 
delayed access to the ground instance and the ground support has time-delayed access to the in-space instance. 



A. Wide-Spread Collaboration on Preliminary Schedule 

Collaboration is cost effective because those with the best knowledge are able to contribute that knowledge 
directly. For the same reason, collaboration produces the best product. Collaboration on the planning and scheduling 
effort for the preliminary schedule is described by listing what each collaborator contributes. 

• Task Experts - Task experts include hardware developers, scientists, engineering support teams, 
doctors, astrobiologists and others who have first-hand knowledge about the tasks to be done to 
maintain the vehicle/habitats and to conduct the science activities. These experts define the tasks and 
arrange them into the required sequences in order to accomplish the goals. The task definitions include 
the procedure descriptions, the equipment (and operation modes) to be used, the conditions required, 
and the durations. These task models do not directly define the resource amounts required by the tasks; 
resources are defined by the equipment mode models entered by the hardware and systems experts. The 
sequence definitions include the temporal relationships between the tasks, relationships to other 


f Fully distributed concepts of operations will not be implemented for ISS because the paradigm shift would require 
rewriting current international agreements, incur appreciable one-time costs including new software, procedures, and 
training, and the phase over would extend almost to the end of the ISS mission. 
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sequences, windows of opportunity and other data. The information is entered into a central data 
repository used by the scheduling system. 

• Hardware and System Experts - Hardware and systems experts have detailed knowledge about how the 
hardware is integrated into the vehicle and how that hardware can be used. They also have knowledge 
about the software systems and how they behave. The experts enter the equipment mode models into 
the central data repository. For each mode of each piece of equipment, these models define how much 
of each resource is used. For example, an oven for metallurgical analysis of regolith samples has several 
operation modes using different resources (power, inert gases, data rates, etc.) and amounts. The 
hardware and systems experts know how the oven functions and how it is connected to the systems 
(which power bus, which controller, which video bus, etc.). These equipment mode models are used by 
the task experts when defining the tasks; therefore, these models eliminate the need for task experts to 
be hardware experts. 

• Scheduling Cadre - The scheduling cadre interacts with program managers, engineering support teams, 
and the science teams to determine the day-by-day plans. Based on the plan, the cadre submits task 
sequences to the scheduling engine which adds them to the schedule. The scheduling engine accepts 
remote requests into a queue of sequences to be scheduled. The engine combines the task models with 
the equipment mode models to create a complete model including all timing, resources, relationships 
and conditions, and it then schedules the request. The scheduling cadre can use a timeline editor (mixed 
initiative scheduling) to make final tweaks to tire schedule. The modeling and scheduling engine are 
powerful enough that mixed initiative scheduling will be required only in rare circumstances. 

• Crew - The crew can send messages, receive messages, and read the minutes of the various planning 
group meetings. The crew has first-hand knowledge of the in-space situation. The crew can collaborate 
on the development of the preliminary schedule because they can view the task models, the equipment 
mode models, the developing (partial) schedule and the crew can submit scheduling requests to the 
instance of the scheduling engine currently being used by the ground support teams. 

In addition to developing the preliminary schedule, the collaborators also develop a task list of sequences which 
are candidates for adding to the timeline. These may be purely discretionary or they may be sequences that are 
planned for the near future. 

B. Collaboration on Final Schedule 

The final schedule is developed in space. On the day or evening before execution, the preliminary schedule and 
all supporting data are transferred to an instance of the scheduling system which is no-located with the crew. The 
crew has immediate and full access to all features of the system and they are the main contributors to the finalization 
of the schedule. They have first-hand loiowledge of the in-space systems; they know their own preferences and 
needs. They can remove omitted tasks from the schedule so that unused resources are known by the system to be 
available. They can modify the equipment mode models to reflect actual in-situ configurations, and they can modify 
task and sequence models to reflect personal experience. They can add to the schedule by selecting items from the 
proposed task list and submitting them to the scheduling engine so that the tasks are assigned times and so that the 
resource usage is tracked*. The modification to the schedule includes not only tasks done by the crew but also un- 
attended tasks done by automated or autonomous systems such as robots. In rare circumstances the crew could use 
mixed-initiative scheduling to modify the timeline; however, mixed-initiative scheduling can consume a lot of 
valuable crew time. 

Ground support teams collaborate on the final adjustments to the schedule by reviewing modifications to the 
models or by updating the models (updating the earth-based instance and uplinking it). They collaborate on timeline 
additions by reviewing what the crew adds and commenting via text messaging. The ground teams can also use 
remote access to submit new requests to the in-space scheduling engine. 

C. Crew Autonomy 

When a situation arises in space that necessitates modification and execution of the schedule before the ground 
can see the change (due to fight-time delays), the crew can go ahead and make the change. It is essential for the crew 

* On the ISS, task fist items are not submitted to the scheduling engine; the crew selects them and executes them 
whenever they want (the crew notifies the ground of their actions). For this reason, task fist items are limited to 
those that do not have difficult timing requirements, do not use scarce shared resources,' and they are limited to tasks 
that are done by the crew. Additionally, the ISS crew cannot see the scheduling models of the tasks, only the 
procedures. 
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and the in-space vehicle or habitat to be able to function if there is an extended communication loss. The crew may 
need to extend the timeline for a few hours or for many days. The installation of a complete planning and scheduling 
system in space will provide the needed capability. 

IK. Collaborative Scheduling Software 

Enabling wide-spread and crew-to-earth collaboration on daily schedules as described in the preceding concept 
of operations requires major, but evolutionary, changes in scheduling software. In addition, a robust communication 
infrastructure designed for long round-trip communication delays is needed. Current development efforts are 
underway on delay-tolerant networking, internet in space, and publish/subscribe methods. The appendix describes 
interplanetary networks and the message bus architectures. Other communication infrastructure elements are 
planned. Relay satellites will orbit Mars to provide communication for the 12 hours per day during which the habitat 
will be on the far side. Additionally, a relay satellite in orbit around the sun will provide communication when the 
sun is directly between the earth and Mars (in worst cases, the sun-occultation communication blockage could be 
two weeks long) . 

The salient features of a scheduling system which can support the collaboration-based concept of operations are 
a comprehensive modeling schema that represents all the constraints, an automatic scheduler that understands the 
models and produces a desired schedule, remote access to die scheduling system, a human interface that is user 
friendly to all users including the crew, and the ability to perform over a delay-tolerant network. Figure 3 shows the 
components of such a scheduling system and how they are used by the collaborators. There would be two instances 
of the scheduling system, one on earth and another in space. The earth-based instance supports wide-spread 
collaboration on the preliminary schedule - the ground support teams being the primary contributors and the crew 
offering limited contributions. The in-space instance supports collaboration on the final schedule with the crew 
being the primary contributors and the ground support offering limited contributions. 



Figure 3. Software and Infrastructure 


The crew will have little time to work on the schedule development. Most equipment models and task models 
will be pre-constructed before transferring them to the in-space software. Most of the schedule will be developed on 
earth. After the locus of development moves to space, the ground can review schedule additions and changes made 
by the crew when made far enough in advance of execution; but the crew doesn’t have time to “discuss” the changes 
via text messages. Some crew changes to the schedule will be in response to the ongoing situation and cannot wait 
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for the light-time delay for review and oversight (these changes can be called real-time replan n i n g). The modeling 
schema and the scheduling engine must automatically produce valid schedules. 

A. Equipment Mode Modeling 

In space, as on earth, most tasks are accomplished using equipment. Most equipment have modes of operation: 
e.g., a microwave oven has defrost, reheat, and cook. The microwave oven’s power requirement for each mode is 
predefined. On a space platform, the characteristics of each piece of equipment are well-known to those building and 
integrating the equipment into the platform systems. The equipment and their modes may be modeled independently 
of the tasks that will use the equipment. Equipment mode models may use multiple resources and may use other 
equipment in specified modes. Equipment mode models can describe a hierarchy of constraints and alternate 
resources. Equipment models allow low-level resources such as power to be hidden from the task modeler. The task 
modeler can only request these low-level resources by selecting equipment that uses them. Using equipment modes 
to model resource usage is an extension of a method previously proposed in Ref. 3. 

Earth-based collaborators will build these models using a distributed- via-remote-access feature of the scheduling 
system to build models in a central data repository. Using a record locking or record checkout method allows 
multiple users to work at the same time as long as they work on different equipment models; revision control is built 
into the system. All collaborators can view the data of other collaborators. 

The in-space crew can view the models in the earth-based repository via the delay-tolerant network. After the 
data is transferred to the in-space instance, the crew, using their knowledge of the local configurations, can make 
needed modifications to the models. The model viewing and editing software must be usable by the crew. The earth- 
based support teams can review the crew’s changes to the models by either remote display or by transferring a copy 
of the datasets back to earth. 

B. Task Modeling 

A specification of the types of goals, states, activities, equipment (resources) and constraints necessary to 
achieve an objective is called a task model. Task models can range from simple to complex and can depend heavily 
on the capabilities of the scheduling system that will use them. For the most part, earth-based task experts will 
construct, review, and test the models before flight. The modeling schema needs to represent all the requirements so 
that automatic scheduling can be employed; it also needs have a straightforward representation so that the task 
experts (technicians, scientists, etc.) can easy enter the models; and it needs to be easy to use so that all 
collaborators, including the crew can understand the models. A possible modeling schema has been previously 
proposed (Ref. 4); some of the key features are: 

• Decomposition of the operations into salient components - Operations are decomposed into tasks that 
define resource requirements and sequences that define relationships between tasks. Sequences can also 
contain other sequences, repeated tasks and sequences, and optional tasks and sequences. 

• Rich expression of the relationships between components - Common-sense representations of temporal 
relationships using everyday concepts like sequential, during, and overlap. Innovative enhancements to 
represent the continuance of resource usage between tasks, the interruption of tasks, minimal percent 
coverage, and temporal relationships to outside tasks have been added to the modeling schema. 

• Public services - The modeling schema also includes the concept of public services - models that are 
scheduled at the request of another model. 

• Flexibility and nuances - Variable timing, alternate resources and sequences, optional items, and other 
nuances are modeled. 

The collaborators use the same type distributed- via-remote-access features as the equipment model builders to 
access a central data repository. Normally, all collaborators can view the data of other collaborators; however, 
models containing sensitive information may be hidden to some collaborators, but never to the crew. The builders of 
task models can submit their models to the scheduling engine to test the models for validity and usability. 
Depending on the concept of operations, the results of scheduling can be part of the developing schedule or they can 
be tested only. 

Like equipment models, the in-space crew can also view the task models via the delay-tolerant network. After 
the data is transferred to the in-space instance, the crew, based on their local knowledge or based on their personal 
preferences, can modify the task models. Complex syntactical languages, difficult to navigate user interfaces, or a 
modeling schema that doesn’t match the real world could render such a system nearly useless to the crew. The earth- 
based support teams can review the crew’s changes to the models by either remote display or by transferring a copy 
of the datasets back to earth. 
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C. Automatic Scheduling 

Automatic scheduling will be the primary mode of developing the task schedules. An incremental scheduling engine 
has characteristics which enable supporting multiple collaborators simultaneously contributing to the development 
of one schedule. An incremental engine is fed by a queue of scheduling requests (sequences of tasks). The engine 
adds each scheduling request to the schedule without adjusting the times of already-scheduled tasks and without 
introducing constraint violations or resource overbooking. The core logic of an incremental engine is usually an 
implementation of a greedy algorithm (Ref. 5); that is, it makes choices based only on scheduling the current 
request. These engines may use analytical, heuristic, 
algorithmic and/or artificial intelligence techniques. 

Incremental scheduling engine usage is depicted in Fig. 4. 

Some scheduling requests are emphasized to show that they 
may be very complex. The figure also shows that multiple 
queues from multiple remote users may be merged into a 
single queue.. 

As an incremental scheduling engine processes a 
sequence, it will search for a near-optimum schedule for the 
multiple tasks of the sequence being scheduled 5 . The tasks 
always have temporal relationships to each other and may 
share the same resources. However, all tasks scheduled by previous scheduling requests are locked, and the residual 
resource profiles are treated as initial resource profiles for the current request. 

Collaborators use remote access to submit scheduling requests from the repository of task models. Multiple 
collaborators can submit to the queue simultaneously. The scheduling system provides the ability for all users to see 
the current schedule as it is being developed. The crew can used the delay tolerant network to submit scheduling 
requests and to view the timeline. 

Incremental scheduling engines and their usage is discussed in detail in Ref. 6. 



Figure 4. Incremental Engine Usage 


D. Mixed-Initiative Scheduling 

Mixed-initiative scheduling refers to building a timeline using a timeline editor; i.e., it is a manual process. 
Mixed initiative is used when the contributor knows requirements that are not described in the scheduling requests, 
the scheduling engine is weak, only a few new requests are to be added to the timeline, or the user wants to fully 
control the results (Fig. 5). Some schedule editors allow the 
user to move already-scheduled tasks; however, this requires 
the user to- have global knowledge of the scheduling 
requirements**. 

Mixed-initiative schedulers usually have logic to help the 
user avoid violating constraints and allow the user to 
override constraint limits. If the models are complete, the 
editor might invoke iterative-repair logic to move other tasks 
and eliminate constraint violation introduced by a manual 
edit. The editor might invoke an incremental scheduler to 
make slight adjustments to the user’s input; this feature is 
called “snap-to.” Additionally, the editor might use an 
incremental engine to suggest times where tasks can be 
placed without introducing constraint violations. Figure 5. Mixed-Initiative Scheduling 

The timeline editor will display considerable information about the schedule, the models, and the availabilities. It 
will be closely coupled to the data repository and the scheduling engine. It will not operate over the delay tolerant 
network and will be only available to local users. During the development of the preliminary schedule, a cadre of 
highly skilled users, called the “scheduling cadre,” will be the primary users. After the locus of development moves 
to in-space, the crew can use mixed-initiative scheduling, but will do so rarely. 

Mixed-Initiative scheduling is discussed in Ref. 6, 



§ Incremental engines do not provide global schedule optimization. 

** Mixed-initiative scheduling does not automatically provide global schedule optimization. However if the user is 
an expert and the problem is straight-forward, global optimization might be achieved. 
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IV. Conclusion 

As humans explore regions of space where the earth appears as a mere point of light, and round trip 
communication delays exceed half an hour, it will be imperative that the humans on the journey exercise significant 
control over their daily schedule and the schedule of their companion systems. Yet the crew doesn’t have the time to 
do all the scheduling. Scheduling will be a collaborative effort between multiple ground support teams and the crew. 

A new concept of operations calls for developing the preliminary schedule on earth, with the ground teams being 
the primary contributors and the crew providing only minimal input. Once the preliminary schedule is uplinked to 
the in-space location, the crew will become the primary contributors and the ground teams will provide only 
minimal input. The concept is tailored to function effectively in the delayed communication environment 

Planning and scheduling software will evolve to meet the needs of the new concept of operations. Automatic 
scheduling will become the normal way to produce the schedule. Modeling will be partitioned into equipment 
modeling and task modeling so that different experts with different knowledge can contribute effectively. Equipment 
models will reflect the different modes in which the equipment operates and will book all resource and condition 
requirements. Task models will be grouped into sequences showing the temporal relationships of the tasks. An 
incremental approach to scheduling will enable multiple experts to schedule sequences without impacting sequences 
scheduled by other experts (the crew is among these experts). Because the models reflect all the requirements and 
the scheduling engine can produce good schedules, mixed-initiative scheduling will be used rarely. 

The synergy of the new concept of operations, delay-tolerant communication and software, and advances in 
scheduling software will allow the in-space crew and earth-based support teams to collaborate on the scheduling of 
the tasks done by the crew, the operation of the vehicle or habitat, and the operation of the various near-autonomous 
robots and rovers. 


Appendix 

Planning and scheduling is only one application that will depend heavily on a communications framework that 
will carry data between Earth and Mars or in between. Without such a framework, in-space collaborative scheduling 
would be impossible. The cost of spaceflight being prohibitive as it is, much work will be done to leverage existing 
technologies and commercial hardware and software to use them and manipulate them to work in these foreign 
environments. Accomplishing this will necessitate standardizing communication between applications using 
concepts like a message bus which travels over ubiquitous protocols such as the internet modified for light-time 
delay. 


Earth Internet 


Delay-Tolerant Segment 
Relay Relay Relay 


Mars Internet 



Store-and-forward 


Figure 6. Inter-Planetary Internet 



A. Inter-Planetary Internet 

Standardized digital communication devices have revolutionized the way we communicate and interact with 
information. But the foundation of the technology, TCP/IP, does not translate well in a space environment where 
line-of-sight connectivity is intermittent, communications 
have delays and data may have high error rates requiring 
retransmissions. However, the technology of TCP/IP can 
easily be leveraged to create Mars-based internet that 
connects remotely to today’s Earth-based internet. The 
interoperability between the networks is where new 
technology is needed. Based on on-going research, a new 
concept, Delay-Tolerant Network (DTN), is evolving to 
mitigate the delay problem. DTN could employ concepts 
such as store-and-forward message delivery. In store-and- 
forward, relay systems capture incoming data and store it 
locally before transmitting it to the next link in a chain (Fig. 6). If there is a transfer failure, the data will not have to 
travel the complete distance again. DTNs can be used to route data between two traditional TCP/IP networks almost 
transparently to the TCP/IP packets concept. However, many of today’s applications are not designed with such 
Communication delays in mind. Loss of continual heartbeats or continuous data streams would cause many of 
today’s applications to fail as they wait for the next packet to arrive. Therefore, any applications themselves must be 
built with data delays in mind. The applications must be more robust and fault tolerant and should not malfunction 
when there is a long data delay. 
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B. Message Bus 

Message buses standardize information exchange as well as data pathways between two end points. Buses can be 
layered upon DTNs to provide more abstraction between the software and the communication infrastructure 
allowing for the flexibility of architecture upgrades. Most message bus modes include a publish/subscribe protocol, 
sometimes called “pub/sub,” in addition to more direct request/reply connections. 

In the publish/subscribe mode, client applications subscribe to information they would like to be provided. As 
messages pass by, messages that match the requested type are captured by the client API and passed to the 
application. 


References 

Compton, W.D., and Benson, C.D., Living and Working in Space: A History of Sky lab. National Aeronautics and Space 
Administration, Washington, D.C., 1983. 

2 Jaap, J.; & Muery, K.; ‘Putting ROSE to Work: A Proposed Application of a Request-Oriented Scheduling Engine for Space 
Station Operations,” Sixth International Conference on Space Operations (SpaceOps 2000), Toulouse, France, June 2000. 

3 Hagopian, J., and Maxwell, T., “Explicit and Implicit Resources: A Simplified Approach to User Requirements Modeling,” 
SpaceOps 96, Fourth International Symposium on Space Mission Operations and Ground Data Systems, September 1996. 

4 Jaap, J., Davis, E., and Richardson, L., “Maximally Expressive Modeling,” Fourth International Workshop on Planning and 
Scheduling for Space, Darmstadt, Germany, June, 2004. 

5 Cormen, T.H.; Leiserson, C.E.; Rivest, R.L.; and Stein, C.; Introduction to Algorithms, 2nd Edition, Sec. 16, The MIT Press, 
Cambridge, Massachusetts, 2001. 

6 Jaap, J., and Phillips, S., “On Using an Incremental Scheduler for Human Exploration Task Scheduling,” 2006 IEEE 
Aerospace Conference, Big Sky Montana, March 2005. 


9 

American Institute of Aeronautics and Astronautics 



In-Space Crew-Collaborative 
Task Scheduling 

John Jaap 

Mission Operations Laboratory 

1 - 256 - 544-2226 

JohnJaap@nasa.gov 



Presentation Outline 


♦ Introduction 

♦ Light time delays 

♦ Interplanetary Internet 

♦ Message Bus 

♦ Collaboration defined 

♦ Integration 

♦ Concept of Operations 

♦ Wide-spread Collaboration 

♦ Collaboration on Final Schedule 

♦ Collaborative Scheduling Software 

♦ Equipment Mode Modeling 

♦ Task Modeling 

♦ Automatic Scheduling 

♦ Mixed-Initiative Scheduling 

♦ Resources, Conditions, and Autonomous Systems 

♦ Terminology and Standards 

♦ User Interfaces 

♦ Conclusion 

I n-S pace Crew-Co1laboratlve^%>^^gj|^H 
Task Scheduling 
19 June, 2006 . ’Mission 



Introduction 

NASA has a vision to send humans to the moon and Mars. 

♦ These missions are long and stressful. 

♦ 18 months + 4 4 months + return time 

♦ The earth is a point of light 4 No voice conversations with earth 

♦ The astronauts need to control their own schedules. 

4 Meet personal preferences 4 Understand reasons for task times 
4 Have a sense of control over their own actions 

♦ The astronauts need autonomy. 

4 Quick response to anomalies 
4 Extended loss of communication 

♦ Technological advances are available to help 

4 Delay-tolerant networks 
4 Remote-access planning and scheduling systems 
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solar occultation and the 
delay-tolerant network. 


Diagram shows a relay satellite 
trailing the earth by 90 degrees 


in-SpaceQrew-eollaboratiye^ 
Task Scheduling e 

1 9 June, 2006 Mission 


NA'SA.M.SFC; 






/ 


Concept of Operations 


Earth-based 

Support 




%>% ■ : -Mk 

N \ ^ |f Personal Preferences j 








f|| In-Space Crew 


fcl Availability 

| S* “"information J 1 / / 


Availability^. - 
Predictions 


^^^^^Seheduiinri Ftt 




BglLFmal 


Preliminary Development 
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Contributors to Wide-Spread Collaboration 
on Preliminary Timeline 

♦ Task Experts - 
First-hand knowledge about the tasks to be done and how 
to order the tasks to accomplish the goals. 

♦ Hardware and Systems Experts - 

Detailed knowledge about how the hardware performs and 
how it is integrated with systems. 

♦ Scheduling Cadre— 

Knowledge of program goals; produce the detailed 
timelines. Final tweaks to timeline, 

♦ Crew- 

First-hand knowledge of in-space situation, personal 
preferences. 

♦ Other Contributors - 

Provide availabilities, predictions, and simulation of 
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Contributors to Final Timeline 



♦ Crew- 

Modify timeline based on in-space situation, personal 
preferences, etc. 

Modify models based on actual configurations. 

Delete tasks as desired / needed. 

Add tasks as desired / needed. 


♦ Scheduling Cadre - 
Verify actions of crew. 

Modify models and timeline as needed. 



Planning and Scheduling Software 









P&S Software - Modeling 


♦ Equipment Mode Modeling 

♦ Equipment and their modes are modeled independently of 
the tasks that use the equipment. 

♦ Resource and condition constraints are assigned in the 
equipment modes. 

♦ Models can define a hierarchy of constraints and alternate 
constraints. 

♦ Task Network Modeling 

♦ Tasks use equipment in specified modes, variable durations. 

♦ Temporal networks of tasks are defined using relationships 
like during, after, overlap, cyclic, etc. 

♦ Variable timing. 

♦ Optional tasks. 



P&S Software - Scheduling 


♦ Automatic Scheduling 

♦ An incremental scheduling 
engine can support - 
collaboration as defined by 
the concept of operations. 

♦ Mixed-Initiative Scheduling 

♦ Manual process best used by 
scheduling experts only to fine 
tune timeline. 

♦ Can be used to delete tasks. 

♦ Can be used to invoke 
incremental engine to add to 
timeline. 
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P&S Software - Resources, Conditions, and 

Autonomous Systems 


♦ Resources 

(power, camera, storage 
lockers) 

♦ Conditions 

(sunlight, communications, 
weather) 
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P&S Software - Terminology and Standards 

♦ Collaboration by many diverse contributors requires 
standard terminology and standard methods. 

♦ Crew collaboration and crew autonomy require standard 
terminology and software. 

♦ Current / Historic scheduling community is fragmented. 
Examples: 

♦ Terminology: ♦ Approach: 


+ State vs. condition. + Start and end events vs. task duration. 

+ Implicit resource usage. 
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P&S Software - User Interfaces 

♦ Collaboration requires good user interfaces. 

♦ Experts in many diverse fields must become “virtual” scheduling 
experts. 

♦ Scheduling experts must be able to comprehend the 
requirements entered by others. 

♦ The Crew must be 

able to use any part. I 

♦ The Crew will need 
specialized user 
interfaces. 





